podvm-mkosi: support to build s390x fedora image #1753
Conversation
There was a problem hiding this comment.
Very cool! Since the rootfs is modified in the later build steps, I assume we don't use verity?
I assume that's ok, but it would good to point that out in the readme section. I'm also not seeing anything in config files that indicate that verity is not being used, can you elaborate how this works?
podvm-mkosi/build-s390x-image.sh
Outdated
| @@ -0,0 +1,92 @@ | |||
| #!/bin/bash | |||
|
|
|||
| set -eu | |||
There was a problem hiding this comment.
| set -eu | |
| set -euo pipefail |
There was a problem hiding this comment.
Sure, add pipefail.
Because we set Bootable=no and output Format=directory for s390x, mkosi will skip partition settings as well as verity.
There was a problem hiding this comment.
thanks, can we add this context to the Readme?
| @@ -75,3 +75,27 @@ reduce complexity of configuration and CI and shall not be seen as open to-dos. | |||
|
|
|||
| - Deployed images cannot be customized with cloud-init. Runtime configuration data is retrieved | |||
| from IMDS via the project's `process-user-data` tool. | |||
|
|
|||
| ## Build s390x image | |||
| Since the [nix OS](https://nixos.org/download/#download-nix) does not support s390x, we can use the mkosi **ToolsTree** feature defined in `mkosi.conf` to download latest tools automatically: | |||
There was a problem hiding this comment.
ToolsTree is interesting. could this be replacement for the nix flake on all architectures? It would be good to have a common way, and if it supports reproducible builds that could be an option.
There was a problem hiding this comment.
I looked into it, mkosi still needs certain tools to be present on the host, so a py virtualenv + ToolsTree cannot fully replace nix yet
There was a problem hiding this comment.
If it's doable, I like the idea to also use ToolsTree for x86 for alignment. Maybe worth to try.
There was a problem hiding this comment.
I just tried ToolsTree on ubuntu host to build the fedora image
There was a problem hiding this comment.
On my side it was lacking the yum/rpm tools that are used to bootstrap a ToolsTree, but it might be due to an outdated local env. we should look into this, but it doesn't have to be in the scope of this PR.
podvm-mkosi/build-s390x-image.sh
Outdated
| chroot $dst_mnt systemctl enable cloud-init-local.service | ||
| chroot $dst_mnt systemctl enable cloud-init.service | ||
| chroot $dst_mnt systemctl enable cloud-config.service | ||
| chroot $dst_mnt systemctl enable cloud-final.service | ||
|
|
||
| # disable this service since we already have "NetworkManager-wait-online.service" | ||
| chroot $dst_mnt systemctl disable systemd-networkd-wait-online.service |
There was a problem hiding this comment.
why do we perform those systemctl enable steps here? (instead of using a preset file like ./podvm-mkosi/mkosi.skeleton/usr/lib/systemd/system-preset/20-coco-sys.preset?
There was a problem hiding this comment.
mkosi.postinst would also be a good candidate
There was a problem hiding this comment.
I tried to use mkosi.postinst.chroot, but not sure why, the changes are revert in steps "Applying presets…".
Anyway, I try to use mkosi.finalize.chroot, and it works well.
Package system with mkosi and generate bootloader with zipl Signed-off-by: Lei Li <genjuro214@gmail.com> Signed-off-by: Lei Li <cdlleili@cn.ibm.com>
|
@mkulke , thanks for your comments. I tried to address them and update the commit. |
There was a problem hiding this comment.
LGTM, great work.
nit: it would a useful to add a sentence or two about the specific of this image since it doesn't use a verity protected rootfs and is running cloud-init. both have some implications for the integrity of the image (compared to the x86 images).
There was a problem hiding this comment.
LGTM,
I like the idea to use ToolsTree for x86 also and we can investigate/change it in new PR. thanks! @genjuro214
According to #1640 , there are 2 problems for mkosi to build s390x images:
mkosi.confto download latest tools automatically:We need run mkosi from the repository:
git clone -b v21 https://github.com/systemd/mkosi ln -s $PWD/mkosi/bin/mkosi /usr/local/bin/mkosi mkosi --versionFor the new mkosi release, there is an issue to set environment (#1746). Instead, we try to use profile as suggested in mkosi community (systemd/mkosi#2500).
I tested the s390x qcow2 image in libvirt environment, and it should work.
I try to avoid impacts to x86 images, which can still be run with nix, and s390x changes will not be picked up for the Match rules.
I also build a new x86 image, but I don't have AWS environment to verify it. Since UEFI is enabled, I can start the VM with following command on ubuntu 22.04 host:
However, it seems current libvirt provider cannot support UEFI image on a host with Intel processor. I noticed we can configure
LIBVIRT_LAUNCH_SECURITYandLIBVIRT_FIRMWAREfor UEFI, but it requires SEV (AMD Secure Encrypted Virtualization) support on the host, but I don't have an AMD host.